Method and Apparatus for Delivering Consumer Entertainment Services Accessed Over an Ip Network

ABSTRACT

The present invention provides IP-centric, multi-channel, time-shifted and real-time telecommunications services to a plurality of system users. The system can capture both digital and analog multi-channel feeds and, through a cross-connect layer, can convert the signals to a digital format and subsequently send them to an encoder to be compressed. The encoding process can use a firmware upgradeable software developed to decrease data bitrates while retaining quality of the information at a desired level. The encoded, compressed signals may either be stored on a data-on-demand server for later viewing services, such as television/video-on-demand or audio-on-demand, or may be streamed directly to system users using a Media Streaming Subsystem (MSS). The MSS can be responsive to a system user request and operative to forward a selected stream of compressed digital data to the system user via a gateway means. The system can include a System Controller that can provide management and control of the system components and services provided by the system. The gateway means is able to receive compressed digital data from the Media Streaming Subsystem and transmit that data to a system user sending a request over a communication network. A cable modem, DSL modem or other appropriate interface can be located at each system user&#39;s location, thereby providing a means for sending multiple signal sources to a system user&#39;s Local Area Network (LAN) to which the User Computing Device(s) (UCD) of a system user are connected. The UCD receives the compressed data from the gateway means, subsequently decodes this compressed data and presents this decompressed information to the system user via a presentation system which may or may not be integrated into the UCD, thereby providing the requested entertainment services to the system user.

FIELD OF THE INVENTION

The present invention pertains to a system for providing consumerentertainment services and in particular to a system and method forproviding video and audio data over broadband wide area networks.

BACKGROUND

Consumer entertainment services, including video-on-demand (VOD) andpersonal video recorder (PVR) services can be delivered usingconventional communication system architectures. In conventional digitalcable systems, a channel is dedicated to the user for the duration ofthe video. VOD services that attempt to emulate the display of a digitalversatile/video disk (DVD) are delivered from centralized video serversthat are large, super-computer style processing machines. These machinesare typically located at a metro services delivery center supported on acable multiple service operator's (MSO) metropolitan area network. Theconsumer selects the video from a menu and the video is streamed outfrom a video server. The video server encodes the video on the fly andstreams out the content to a set-top box that decodes it on the fly; nocaching or local storage is required at the set-top box. In suchcentralized video server architecture, the number of simultaneous usersis constrained by the capacity of the video server. This solution can bequite expensive and difficult to scale. “Juke-box” style DVD serverssuffer from similar performance and scalability problems.

Internet Protocol (IP) streaming can be used to avoid dedicating channelbandwidth to each user. IP streaming has been designed to overcome theshortcomings of typical IP networks by providing codecs that arefriendlier to packet loss and can tolerate multiple available bit-rates.Thus, the same video stream can continue to play, albeit at a lowerquality, should the network suddenly get congested.

Personal video recorder services, for example TiVo and Replay TV, allowconsumers to record selected programs on local storage and play themlater, at their convenience. Such services are popular with consumers asthey replace the sequentially-accessible and cumbersome videotapes withrandomly-accessible hard drives. Such hard-disk enabled devices bringsuperior recording and replay capabilities, such as instant fast-forwardand recording of multiple programs simultaneously.

However, the capabilities offered by such PVRs can come at a significantprice. Although hard drive prices have dropped significantly, they stillmake up a large portion of the cost of a personal video recorder. Volumeproduction and other logistics have kept the median price of hard drivesat an optimal level for personal computers, for example, but relativelyhigh for low-cost consumer devices like, for example, PVRs. Hard driveshave a mean time between failure (MTBF) of approximately 300,000 hours,or around thirty years. As the number of hard drives deployed goes up,so does the frequency of failure. For example, for a customer base of30,000 users, the service provider may be replacing about 100 harddrives every month. Therefore, from a service provider perspective, thefrequency and cost of servicing customer premise equipment (CPE) goes upwith the number of users. Furthermore, additional power and coolingrequirements make the reliability of a hard disk enabled devicesignificantly lower than the same device without a hard drive.

While consumers and service providers face the above issues, contentproviders face other issues, including a serious risk of piracy.Digitally recorded content can easily be shared over high-capacitynetworks in addition to being written to writable CDs, DVDs and otherstorage media.

Having particular regard to typical DVD players, they operate at aminimum 8 times (150 KBps) speed, producing 8 times 150 KBps times 8bits/byte=9.6 Mbps with a latency of <100 ms, for example. DVD playersrequire predictable throughput in a burst-mode (e.g., constant 128 KBblock fetches every 100 milliseconds).

Current video servers employ powerful processors, or a network ofpowerful processors, to serve video content. The number of simultaneoususers they can support is constrained by the capacity of the videoserver. Typical video servers encode their content on the fly, forexample for Real Media or Windows Media formats, and set-top-boxesdecode on the fly.

Video-on-demand services have been known in hotel television systems forseveral years. Video-on-demand services allow users to select programsto view and have the video and audio data of those programs transmittedto their television sets. Examples of such systems include: U.S. Pat.No. 6,057,832 disclosing a video-on-demand system with a fast play and aregular play mode; U.S. Pat. No. 6,055,560 disclosing an interactivevideo-on-demand system that supports functions normally only found on aVCR such as rewind, stop, fast forward, etc.; U.S. Pat. No. 6,055,314which discloses a system for secure purchase and delivery of videocontent programs over distribution networks and DVDs involvingdownloading of decryption keys from the video source when a program isordered and paid for; U.S. Pat. No. 6,049,823 disclosing an interactivevideo-on-demand to deliver interactive multimedia services to acommunity of users through a LAN or TV over an interactive TV channel;U.S. Pat. No. 6,025,868 disclosing a pay-per-play system including ahigh-capacity storage medium; U.S. Pat. No. 6,020,912 disclosing avideo-on-demand system having a server station and a user station withthe server station being able to transmit a requested video program innormal, fast forward, slow, rewind or pause modes; U.S. Pat. No.5,945,987 teaching an interactive video-on-demand network system thatallows users to group together trailers to review at their own speed andthen order the program directly from the trailer; U.S. Pat. No.5,935,206 teaching a server that provides access to digital video moviesfor viewing on demand using a bandwidth allocation scheme that comparesthe number of requests for a program to a threshold and then, under somecircumstances of high demand makes another copy of the video movie onanother disk where the original disk does not have the bandwidth toserve the movie to all requesters; U.S. Pat. No. 5,926,205 teaching avideo-on-demand system that provides access to a video program bypartitioning the program into an ordered sequence of N segments andprovides subscribers concurrent access to each of the N segments; U.S.Pat. No. 5,802,283 teaching a public switched telephone network forproviding information from multimedia information servers to individualtelephone subscribers via a central office that interfaces to themultimedia server(s) and receives subscriber requests and including agateway for conveying routing data and a switch for routing themultimedia data from the server to the requesting subscriber over first,second and third signal channels of an ADSL link to the subscriber.

IP-centric, multi-channel, time-shifted and real-time telecommunicationservices designed to receive requests from subscribers for programs orservices such as high speed Internet access or access to other broadbandservices has not yet completed development. Such systems receiveupstream requests and deliver requested programs with associated video,audio and other data, as well as bidirectional delivery of InternetProtocol packets from LAN or WAN sources coupled to the head-endbidirectional delivery of data packets to and from T1, T3 or other highspeed lines of a broadband network. Therefore there is a need for anIP-centric, multi-channel, time-shifted and real-time telecommunicationsservices system that can deliver a plurality of services to users in oneintegrated system with greater efficiency and better features.

This background information is provided for the purpose of making knowninformation believed by the applicant to be of possible relevance to thepresent invention. No admission is necessarily intended, nor should beconstrued, that any of the preceding information constitutes prior artagainst the present invention.

SUMMARY OF THE INVENTION

An object of the present invention is to provide a method and apparatusfor delivering consumer media services accessed over an IP network. Inaccordance with an aspect of the present invention, there is provided asystem for providing a plurality of system users IP-centric,multi-channel, time-shifted and real-time telecommunications servicesincluding live television, television-on-demand, video-on-demand,streaming audio, audio-on-demand, said system comprising: a compresseddata creation subsystem for receiving multiple data signal streams eachhaving one of several industry standard communication formats, and forconverting the incoming data signal streams into compressed digitaldata, said compressed digital data being created using a predeterminedcompression scheme; a storage means for storing selected compresseddigital data and permitting stored compressed digital data to beretrieved therefrom; a media streaming subsystem for receiving andforwarding streams of compressed digital data, said media streamingsubsystem being responsive to a user request and operative to forward aselected stream of compressed digital data from either the compresseddata creation subsystem or the storage means to a gateway means; agateway means for receiving said compressed digital data from the mediastreaming subsystem and preparing said compressed digital data fortransmission over a broadband communication network to a user sendingthe user request; and a user computing device, connected to thebroadband communication network, for receiving the selected stream ofcompressed digital data and the user computing device decompressing andpresenting said selected stream of compressed digital to the systemuser.

In accordance with another aspect of the present invention, there isprovided a method for providing a plurality of system user IP-centric,multi-channel, time-shifted and real-time telecommunications servicesincluding live television, television-on-demand, video-on-demand,streaming audio, audio-on-demand, said method comprising: receivingmultiple incoming data signal streams each having one of severalindustry standard communication formats and converting the incoming datasignal streams into compressed digital data using a predeterminedcompression scheme; storing selected compressed digital data; selectinguser requested compressed digital data from the compressed digital dataand the selected compressed digital data in response to a user requestand forwarding the user requested compressed digital data to a gatewaymeans; receiving the user requested compressed digital data in thegateway means and preparing the user requested compressed digital datafor transmission over a broadband communication network to a usercomputing device sending the user request; and receiving the userrequested compressed digital data by the user computing device anddecompressing and displaying the user requested compressed digital databy means of the user computing device.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a schematic system overview according to one embodiment of thepresent invention.

FIG. 2 is a schematic view of the system architecture according to oneembodiment of the present invention.

FIG. 3 is a schematic view of the head-end portion of the systemarchitecture illustrated in FIG. 2.

FIG. 4 is a schematic view of the transportation network of the systemarchitecture illustrated in FIG. 2.

FIG. 5 is a schematic view of the home network of the systemarchitecture illustrated in FIG. 2.

FIG. 6 is a block diagram of the functional elements of a set-top boxaccording to one embodiment of the present invention.

FIG. 7 is a block diagram of the software elements integrated into aset-top box according to one embodiment of the present invention.

FIG. 8 is a block diagram illustrating interconnectivity betweenmultiple modules and elements for system control according to oneembodiment of the present invention.

FIG. 9 illustrates the program flow control of the encoding/transcodingsystem according to one embodiment of the present invention.

FIG. 10 illustrates a encoding/transcoding system method according toone embodiment of the present invention.

FIG. 11 illustrates a encoding/transcoding system method according toanother embodiment of the present invention.

FIG. 12 illustrates a encoding/transcoding system method according toanother embodiment of the present invention.

DETAILED DESCRIPTION OF THE INVENTION Definitions

The term “telecommunications services” is used to define a variety ofservices including live television, time-shifted television programmingavailable on demand, video-on-demand, near video-on-demand, streamingaudio, audio-on-demand, broadband Internet access, and other broadbandservices as would be readily understood by a worker skilled in the art.

The term “encoder” is used to define a computing means that is able toencode or transcode data into a predetermined format.

The term “computing means” is used to define a computing device capableof performing a predetermined set of functions that are associated withthe computing means, for example a computing means can be a microchip,microprocessor, or other computing means as would be readily understoodby a worker skilled in the art.

The term “User Computing Device” (UCD) is used to define Set-top Boxes(STBs), digital phones, personal computers, digital VCRs, personaldigital assistants (PDAs) or other like devices capable of receivinginformation from a broadband communications network, as would be readilyunderstood by a worker skilled in the art.

Unless defined otherwise, all technical and scientific terms used hereinhave the same meaning as commonly understood by one of ordinary skill inthe art to which this invention belongs.

The present invention provides IP-centric, multi-channel, time-shiftedand real-time telecommunications services to a plurality of systemusers. Such telecommunication services can include live television,television-on-demand, video-on-demand, streaming audio, audio-on-demand,broadband Internet access, and other broadband services. The delivery ofmedia services can typically be referred to as the triple-play: video,voice and data. The system can capture both digital and analogmulti-channel feeds and, through a cross-connect layer, can convert thesignals to a digital format and subsequently send them to an encoder tobe compressed. The encoding process can use a firmware upgradeablesoftware developed to decrease data bitrates while retaining quality ofthe information at a desired level. The encoded, compressed signals mayeither be stored on a data-on-demand server for later viewing services,such as television/video-on-demand or audio-on-demand, or may bestreamed directly to system users using a Media Streaming Subsystem(MSS). The MSS can be responsive to a system user request and operativeto forward a selected stream of compressed digital data to the systemuser via a gateway means. The system can include a System Controllerthat can provide management and control of the system components andservices provided by the system. The gateway means is able to receivecompressed digital data from the Media Streaming Subsystem and transmitthat data to a system user sending a request over a communicationnetwork, wherein this communication network can include, for example, aDigital Subscriber Line (DSL), Hybrid Fibre-Coax (HFC), wirelessInternet, or other communication network. A cable modem, DSL modem orother appropriate interface can be located at each system user'slocation, thereby providing a means for sending multiple signal sourcesto a system user's Local Area Network (LAN) to which the User ComputingDevice(s) (UCD) of a system user are connected. The UCD receives thecompressed data from the gateway means, subsequently decodes thiscompressed data and presents this decompressed information to the systemuser via a presentation system which may or may not be integrated intothe UCD, thereby providing the requested entertainment services to thesystem user.

FIG. 1 is an overview of the functional architecture of one embodimentof the present invention. The content providers 10 provide the contentto the system and the service provider 20 prepares the content fortransmission over a transport network 30 to the house network 40 whereinthe content is subsequently displayed to the user.

FIG. 2 illustrates the system architecture of one embodiment of thepresent invention. The system comprises a head end 200 enabling thecollection and encoding of the signals, the transportation network 210enabling the transmission of the information from the head end to auser, and the home network 220 enabling a user to decode the signalsfrom the head end for subsequent presentation to the user. FIG. 3illustrates the various components of the head end including the systemcontroller 310, video on demand (VOD) server 320, billing system 330,the condition access system (CAS) 340 and the encoding/transcodingsystem 350. The encoding/transcoding system forms a portion of thecompressed data creation subsystem. FIG. 4 illustrates the variouscomponents of the transportation network for broadcasting media over anIP network, wherein this transport system forms a portion of the mediastreaming subsystem. FIG. 5 illustrates the home network for a DSL basedIP connectivity. The home network illustrates a personal computer (PC)and a set-top box (STB) sharing an Internet connection via a homerouter, wherein the personal computer and a set-top box are examples ofuser computing devices.

In one embodiment, the present invention the Compressed Data CreationSubsystem (CDCS) receives multiple data signal streams and converts theincoming data signal streams into compressed digital data using DynamicEncoder Allocation (DEA). Rather than having dedicated hardware encodersfor particular streams of data, system resources can be improved bydynamically routing data to less active non-dedicated hardware encoders.For example, if a sequence of frames of video is complex, it can bedivided and routed to multiple hardware encoders to significantly reducecompression time. In turn, further data can be routed to less activehardware encoders that may have compressed less complicated data and arefree to take on more data. In one embodiment, for full redundancy ofencoders, which is typically required by most commercial applicationswith critical fault tolerance, the DEA requires at least one standbyencoder per dedicated encoder.

In one embodiment, the present invention comprises a set-top box (STB)that is able to decode transmitted compressed data and output a signalto a display device, such as a television and/or audio receiver. The STBcan include a polling/interrupt protocol enabling IP communication inthe STB with a multi-processor coupled implementation comprising adigital signal processor (DSP) and a Central Processing Unit (CPU). Thiscoupled implementation of a DSP and CPU can provide for an increase inproductivity of the DSP, as the operating system and other applicationssuch as an Internet browser can reside on the CPU. This coupledimplementation can overcome numerous limitations of having only a DSP byallowing increased functionality through a larger instruction set, and amore flexible environment with a wide variety of software applications.The set-top box can be connected to a high-speed, quality-of-service(QoS) enabled communications network providing access to the gateway.The polling/interrupt protocol can enable unique communication between aDSP and an Interprocess Communication/Remote Procedure Call (IPC/RPC)stack.

In one embodiment, all system components and subsystems are capable ofreconfiguring the resident operating system and application softwarewith software that is downloaded via the network. This capabilityenables the system operator to upgrade system components and subsystems,including set-top-boxes, to a new software version via the network. Inthis embodiment, since both the STB and encoder software can beupgradable, the system may prevent malicious boxes from connecting tothe networks. For example, all firmware upgrades can be validated beforethe update, otherwise it may be possible to develop a worm or virus thatcould eventually disrupt the entire network.

In one embodiment, the system can employ an encryption method thatfacilitates verification and source identification of the flash softwareupgrade. Each STB on the network can be monitored so they have thelatest firmware. In order to motivate people to upgrade their STB, forexample for those who filter out upgrade requests, the system canupgrade the codec, if using a proprietary codec, for both encode anddecode such that old firmware releases will be rendered non-functional.

In one embodiment, the Media Streaming Subsystem can respond to systemuser inputs by forwarding compressed digital data in real time, whereinthis compressed digital data represents a real time program receivedfrom the Compressed Data Creation Subsystem (CDCS) which itself isreceiving the program data stream via satellite, cable or other sources.Alternatively, the MSS may respond to a system user's input byretrieving the requested data file from the system's storage unit, forexample a Data on Demand (DOD) server or a Video on Demand (VOD) serverand subsequently transmitting it to the system user. A server in theCDCS may manage the data creation for the streaming of the data feed.The real time data may be channeled to the storage unit and the MSSthrough a switch. In a more complex system, a plurality of switches canbe used with a plurality of streaming media servers and storage units.The switches may, for example, be fibre channel switches. Alternatively,the switches may be Ultra SCSI, Serial-ATA (SATA), or SATA/II switches.For example, Small Computer System Interface (SCSI) is a set of evolvingANSI standard electronic interfaces that allow personal computers tocommunicate with peripheral hardware such as disk drives, tape drives,CD-ROM drives, printers, and scanners faster and more flexibly thanprevious interfaces. Serial ATA is a faster, flexible, scalable andenhanced replacement for Parallel ATA, with SATA/II providing additionalswitching logic. The Media Streaming Subsystem can manage the userrequests by retrieving the requested data from a Data-on-Demand Serveror from the Compressed Data Creation Subsystem, encoding the data basedon a predetermined codec, and transmitting the encoded data to thesystem user through the broadband communication channels.

Compressed Data Creation Subsystem

The Compressed Data Creation Subsystem (CDCS) provides a means forreceiving a plurality of data signal streams and converting thesestreams into compressed digital data for subsequent storage in thestorage means or for subsequent transmission to a system user over an IPbased broadband communication system.

Data streams received by the CDCS can comprise sources such as digitaland analog satellite signals, as well as off-air television feeds orother sources as would be readily understood by a worker skilled in theart. Appropriate digital satellite receivers, analog satellitereceivers, demodulators, etc. can receive the signals and may connect toa cross-connect layer of the CDCS. For digital signals, for example, theconnection between the digital receiver(s) and the cross-connect layercan be made through a Digital Video Broadcasting Asynchronous SerialInterface (DVB-ASI), which provides simple transport and interconnectionof, for example, MPEG-2 streams between the equipment. The DVB-ASIchannels can have the capabilities of transporting MPEG Single ProgramTransport Streams (SPTS) or Multi-Program Transport Streams (MPTS), eachwith a different data rate. For analog signals, for example, theconnection between the receiver or demodulator and the cross-connectlayer can be made using a Serial Digital Interface (SDI) which cantransport both composite and component digital video. The cross-connectlayer can transfer a plurality of channels to an Encoder Subsystem. Itwill be understood by those skilled in the art that the architecture ofthe CDCS is designed to be scalable, so that any increase in the numberof the inputs may be easily absorbed by the system.

The information flow from the CDCS can be directed to at least twopossible destinations. One destination may be the storage means, whereinthe incoming programming data may be stored for future retrieval anduse. Additionally, the incoming data may be directed to the gatewaymeans and routed to system users that requested real-time programming,for example a real-time news broadcast. Alternatively, system userrequests for previously stored programming can be processed by the MediaStreaming Subsystem, which can facilitate the request through aData-on-Demand (DOD) server that is associated therewith or with thestorage means. Such requests can be processed and managed in a timeefficient manner wherein the Media Streaming Subsystem can locate therequested programs, retrieves the programs and forwards them to thegateway means to be transmitted to the requesting system user, therebyenabling “real-time” display of the program by the system.

The Encoder Subsystem comprises two or more encoders that are able tocompress the data using a predetermined compression scheme. The codecand software used to compress the data can be fully upgradeable and nothardwired into the encoder chips. The Encoder Element Manager (EEM),which may be a separate dedicated CPU in the System Controller, can beused to control the data flow between the cross-connect layer and theencoder chips. The output from the encoders can be either at a constantbit rate, or a variable bit rate with specified maximum thresholds, asdetermined by the software and codec being used at any given time. Theencoders can receive normal base band audio/video to be encoded, oralready compressed audio/video streams to be transcoded using thesystem's associated codec. Each encoder may be assigned a unique Unicastor Multicast IP address by the Encoder Element Manager. The encoders canpass the data on to the Media Streaming Subsystem, which can determinewhether or not the data is to be stored before passing the informationon to the gateway means. In one embodiment, the encoded data may beformatted into IP-based data packets suitable for transmission over abroadband network such as the Internet, for example, prior to storagewherein the digitized, encoded and formatted IP-based data packets canbe indexed by the Media Streaming Subsystem and stored in large capacitystorage units.

In one embodiment of the present invention the Compressed Data CreationSubsystem can receive multiple data signal streams and convert theincoming data signal streams into compressed digital data using DynamicEncoder Allocation (DEA). Rather than having dedicated hardware encodersfor particular streams of data, system resources can be improved bydynamically routing data to less active non-dedicated hardware encoders.For example, if a sequence of frames of video is quite complex, then itcan be divided and routed to multiple hardware encoders to significantlyreduce compression time. In turn, further data can be routed to lessactive hardware encoders that may have compressed less complicated dataand are free to take on more data. In one embodiment, for fullredundancy of encoders, which is typically required by most commercialapplications with critical fault tolerance, at least one standby encoderis provided per dedicated encoder.

To further pipeline the encoding process, in one embodiment eachhardware encoder can comprise multiple Digital Signal Processors (DSPs)coupled with a Central Processing Unit (CPU). The master application,running on the CPU, can manage the flow of raw video units. In oneembodiment, the video units are composed of 1 second durations of video.Each DSP can be responsible for encoding a video unit and sending backthe compressed result to the master application; wherein the encodedvideo units are in turn, sorted, wrapped in a system stream and thentransmitted to the Media Streaming Server. The master application canmonitor the DSPs with which it is coupled and can improve systemresources by dynamically routing data units to the DSPs that will becomefree first, thus pipelining the encoding process. In addition, if thereis a problem with one of the DSPs, the EEM can ensure that the damagedDSP will not be used, thereby enabling “graceful” failure. This processcan be a scalable solution, as more DSPs can be added to the hardwareencoders to increase the overall speed of encoding numerous datasignals. When the data from a signal to be encoded is more complex, forexample when encoding a video signal that is at a very high resolution,the signal can be accommodated by adding more DSPs to the system.

In one embodiment, each DSP can independently have the ability to adjustthe complexity of the encode and the bit rates based on encodingstatistics by using a Complexity Throttle and Bitrate Throttle,respectively. In order to ensure full frame rate encoding the DSP can beallocated a certain time period to encode a video unit, based on theduration of the unit, the natural frame rate and the number of DSPsencoding in the system. While encoding a video unit, the DSP can adjustthe complexity of the process, using a function, for example a linearfunction, to either a quicker less efficient mode or restore to anatural high efficiency mode. As the encoding is simplified, the bitratewill likely increase. The DSP can also monitor the bitrate of the encodeprocess and ensure that a bitrate never exceeds a threshold set by themaster application, wherein this is termed the Bitrate Throttle. Hence,as the less complex mode is chosen, the bitrate throttle will force thecodec to lower the quality, which in turn makes the content easier toencode. The Complexity Throttle and Bitrate Throttle (CTBT) have asymbiotic relationship to ensure that the bitrate and complexity of theclip never degrade below an acceptable level. Combined with the DEA andthe CTBT, a hardware encoder can seamlessly support encoding of signalsmore complex than originally designed for. In one embodiment, each DSPin an encoder box could be allocated a television channel, whereby theCTBT would act like a StatMUX, sharing an overall bitrate for each VBRchannel.

The encoders can send back status data to the Encoder Element Manager,which may be a separate CPU dedicated to provisioning the hardwareencoders, monitoring the hardware encoders for failures, evaluating theactivity of individual hardware encoders, and managing the data flowbetween them. Specifically, if there is ever a problem with one of thehardware encoders, data can be shifted by use of the Encoder ElementManager to other hardware encoders or backup hardware encoders, therebyminimizing signal interruption.

Having regard to the encoding process, a digital format of a video/TVsignal can be created using a codec, short form of “encoding anddecoding”. When an analog video signal is sent through a codec, thesignal is encoded (transformed) into a digital format. In a digitalvideo signal, for example, every frame is about 2.5 Mbits in size whichcorresponds to about a 75 Mbits per second (Mbps) bitrate based on 30frames per second to limit or eliminate visible flicker. Accordingly, acodec can be designed to also compress the signal to enable videostreaming at lower bit rates. The quality of the digital signal dependson what codec is used. MPEG-2, for example, which is used for DVDs, is alossy codec, data is discarded and one can never retrieve the originaluncompressed signal after encoding. This codec removes as much redundantinformation as possible, such as reducing redundant data that describesmotion. To maintain a high quality of the signal, it necessitates that ahigh bitrate be maintained. Alternately, HuffYUV is a lossless codecwhich compresses video data without having any reduction in quality.HuffYUV, however, is only able to obtain a compression of approximately2:1 to 3:1.

In general, codecs attempt to lower the bitrate by using a selectedcompression/decompression scheme. They all use what is often referred toas “key frames” or “intra frames” (I-Frames) and “inter frames”, whichare often comprised of “predictive frames” (P-frames) and“bi-directional frames” (B-frames). I-frames are frames that contain allimage data to produce a complete picture. Both P-frames and B-frames aredependent on I-frames in order to be displayed. P-frames are frames thatare built from the previous frame (which could be either anotherP-frame, an I-frame or B-frame), and they store only the changes betweenthe two frames. B-frames are similar to P-frames, except that they canbe built from a future frame rather than a previous frame, or from acombination of both a previous frame and a future frame. Typically,B-frames built from two frames can offer substantial improvements infile size over P-frames. As B-frames are dependent on “future” frames,they are often not used in encoding live video.

To lower the bit rate, a codec typically begins by sending an I-framethat contains all image data, and then sending inter frames, usuallyP-frames. The inter frames contain only the changes in the image datacontained since the I-frame. Thus, a digital video stream starts with anI-frame and then can, for example, contain only P-frames until the nextI-frame is sent. A first I-frame contains all the data for a particularimage. Thereafter, the stream may comprise a plurality of P-frames, eachof which contain data reflecting changes made in the image since theI-frame. When the image has changed by a certain amount, another I-framecan be provided to contain all the image data of the changed image.

For example, two frames can each contain all image data of an image (200Kb). The difference between the frames is then determined to create aP-frame at 50 Kb. By sending just the changes from one frame to another,the bitrate needed to transmit the video stream can be significantlyreduced. By minimizing the number of I-frames in the data stream, thebit rate can be further reduced. There are two principal procedures fordeciding how often to provide an I-frame in the video stream, namely, i)a particular interval can be specified (e.g., every 30th frame will bean I-frame); and ii) natural I-frames can be used, wherein an algorithmcan calculate the difference from one frame to another and can decide ifan I-frame is required. Natural I-frames often occur when an imagechanges completely, for example, when switching from one camera toanother or scene changes in a movie.

Switching from a first digital video input stream to a second digitalvideo input stream typically must be done on an I-frame of the secondvideo stream since only an I-frame contains all image data of an image.In one embodiment of the present invention, an I-frame is provided thatis available in less than one second, so that switching can beaccomplished essentially whenever desired.

In a slightly more complicated system, each video stream can have a‘natural I-frame’ encode coupled with an I-frame only channel. When auser requests a channel change, the UCD can connect to an I-framechannel, decode the frame and then connect to the ‘natural I-frame’channel. If the I-frame was a lossless encode of the P frames, therewould be no visible artefacts; however, if the I-frame was a lossyencode of the P frame, the difference, which would typically benegligible, would only propagate until the next natural I frameoccurred. This system would enable instantaneous channel changes andwould offer better compression results than having fixed I-frames everyunit interval. In order to prevent bandwidth overload in rapid channelchanges, it would be advantageous if all I-frame channels aresynchronized and only have 1 or 2 frames every second, such that theI-frame channel would substantially never exceed the threshold bitrateof the system.

Media Streaming Subsystem

The Media Streaming Subsystem provides a means for receiving andforwarding streams of compressed digital information to a system user,wherein these actions can be performed based on a system user requestfor the specific compressed digital information.

The Media Streaming Subsystem receives encoded streaming program datafrom the Compressed Data Creation Subsystem. The streaming program datacan be packetized and prepared for transmission by the Media StreamingSubsystem. In an alternative embodiment, the IP packetization of theencoded signal can be performed by the Compressed Data CreationSubsystem. The data files can be indexed and stored in the storagedevice, thereby available for quick retrieval. The Media StreamingSubsystem may receive a request for a specific file from an inputtedselection by a system user. The Media Streaming Subsystem can retrievethe requested data either from the storage device or from the CompressedData Creation Subsystem and sends the file to the gateway means fortransmission to the system user.

The Media Streaming Subsystem can retrieve data packets corresponding toa program requested by a system user in an efficient manner. In oneembodiment of the present invention, the system user may be locatedanywhere within the network and may access the data using any accessdevice that is broadband enabled. The Media Streaming Subsystem cancommunicate with other modules as required via, for example, an UltraSCSI/fibre channel I/O module.

Having regard to changing compressed data feeds as requested by a systemuser, the Media Streaming Subsystem can ensure a maximum one secondlatency between the channel/stream changes by a system user by encodingat least one I-frame every second. For example, when a system userswitches to a new channel, the new input can be displayed in less thanone second.

As an example, assume that there are 100 video input streams and one iscurrently being broadcast to a particular system user. The other 99streams are also being encoded by the system, with an I-frame for eachstream occurring at least once every second. When a system user switchesfrom one stream to another, there will be a maximum delay of one secondof video data before another I-frame is available to be displayed to thesystem user.

In an alternate embodiment, having regard to changing compressed datafeeds as requested by a system user, the Media Streaming Subsystem caninclude a plurality of buffers for temporarily storing input streamsfrom video sources. The incoming streams comprise an I-frame and aplurality of P-frames. The data from the I-frame can be buffered. Anumber of other buffer locations can each store the I-frame data fromthe same I-frame and, in addition, store the P-frame data from acorresponding sequential P-frame. Accordingly, each buffer locationcontains all the data of a particular image frame (either the I-framedata by itself or the data of the most recent I-frame super-imposed onor combined with all changes to the I-frame). By using the buffer,switching from one video stream to another video stream can beaccomplished at any time rather than only at an I-frame of the actualincoming video stream. Accordingly, switching can be accomplished withsubstantially no loss in the quality of the data. In particular, when anoperator switches to the video stream from a source from another inputstream, the first frame can be from the buffer and all subsequent framescan be from the actual incoming video stream from the source. Becauseeach buffered frame contains the most recent I-frame and any changes,therefore switching can be made at any time and it may not be necessaryto wait for the next I-frame.

As an example of the above alternate embodiment for providing lowlatency between channel changes, assume that there are four video inputstreams and one is to be broadcast to an audience. The other three arebuffered and updated in real time. The first I-frame from each the“waiting” video stream is taken, and every bit that is coming in thestreams is compared with the one in the buffered frame, for therespective stream. If it is the same, (i.e. not changed), it isdiscarded. If it differs from the one in the buffered frame, the old bitis replaced with the new bit. Accordingly, there is always an updatedframe ready for switching. At the moment of a switch, the buffered frameis caused to be the first frame of the switched video stream, and theremaining frames are from the actual incoming video stream.

The Media Streaming Subsystem comprises at least one switch connectingthe CDCS to the MSS. It will be apparent to those skilled in the artthat the switch may be an optical switch or alternatively, an Ethernetswitch, Ultra SCSI switch, or SATA I/II switch may be used. The switchcan facilitate selection and communication between the CDCS, multiplestorage units, and the Media Streaming Subsystem. A System Controllermay be managing the interoperation of one or more media streamingservers contained in the MSS and one or more storage devices.Additionally, a Web Server Subsystem may be presenting the interface tothe user via a web site. It will be understood by those skilled in theart that the Web Server Subsystem and the System Controller may resideon the same physical unit or may be distributed over several servers.The user inputs may be received through the Web Server Subsystem andprocessed by the Media Streaming Subsystem in order to retrieve thevarious data files requested by the system user and pass them on to thegateway means to forward to the requesting system user.

Storage Means

The system comprises a storage means for storing selected compresseddigital data and permitting stored compressed digital data to beretrieved. The storage means can comprise a plurality of storage devicesscaled to store large amounts of data from the encoded data streams. Itwill be apparent to those skilled in the art that the size of thestorage unit is dependant on the number of files that need to be storedon a given system. The storage means can comprise of a RAID array oflarge capacity hard disk drives (HDD), for example. The amount ofstorage capacity required is proportional to the amount of data that hasto be stored. For example, 11 terabytes of storage capacity may be usedto store twenty-four hours of programming over a span of one week,produced for fifty channels for MPEG-2 video at standard definition.Alternately, HDTV will typically require at least four times the datastorage, for example.

The storage means may also contain one or more Data-on-Demand (DOD)servers to deliver content such as Video-on-Demand, Audio-on-Demand,Television-on-Demand, etc. In one embodiment, the DOD server deliversbit streams from the disk, or array of disks, at a constant bit rate.The DOD server can assure that once a stream request is accepted, thestream is delivered at the specified bitrate until the stream ends orthe server is given another command, such as to stop, rewind, fastforward, etc.

In one embodiment of the present invention, one week of televisionprogramming produced for a particular geographic region may be stored inthe storage means. It will be appreciated by those skilled in the artthat the design of the CDCS and the storage means may be scalable inorder to allow larger storage capacities and greater traffic in thesystem.

Delivered data streams can be independent in that they can each bestopped and started independently. Furthermore, these delivered bitstreams may each contain different content (i.e. each being a differentmovie) or a plurality of delivered streams can be from the same contentstream, such as a plurality of video streams containing video data fromthe same movie. Furthermore, the data streams from the same content neednot be synchronized so that more than one viewer can be watching thesame movie simultaneously, although one user started the movie at adifferent time from the other.

There are two general models used for DOD server systems. One is a“pull” model, in which a system user can request information from theDOD server, which then responds to these requests. In such “pull” typesystems, there are inherently-present controls to ensure that data isreceived on time and in a proper sequence even in the event of biterrors, since the receiving device can re-request information or hold arequest until a previous request has been properly received. This “pull”model may, for example, support an IP Unicast environment usingReal-Time Transport Protocols (RTP) or Real-Time Streaming Protocols(RTSP).

The other model for DOD servers is the “push” model, in which the DODserver “pushes” the video stream out with no dynamic flow control orerror recovery protocol. In this “push” model of stream delivery, theserver delivers data streams from the array of disks. The DOD server'srequesting client must assume that once a stream request is accepted,the stream is delivered until the stream ends or the server is told tostop. This “push” model may, for example, support an IP Multicastenvironment using RTP or RTSP.

While the system is capable of both push and pull models, typically thepull model will be used to enable users with more features such asrewinding, fast-forwarding, chapter/scene changing, pausing, etc. Thepush model will more typically be used when a provider wishes torestrict such features.

User Computing Devices (UCD)

The system further comprises one or more User Computing Devices (UCDs)connected to the broadband communication network for receiving selectedcompressed digital data streams and subsequently decompressing thesestreams and presenting them to the system user. The UCDs are capable ofdecoding the compressed data and outputting the information visuallyand/or audibly or sending the decoded signal to another device such as atelevision and/or audio receiver or speakers. The UCD may also becapable of collecting channel information, displaying an electronicprogram guide, and can be used to change channels. The UCD can providesubstantially seamless integration with other IP-based services such asweb surfing, Voice-Over-IP, IP video phone, instant messaging, andeCommerce, for example. In one embodiment, a UCD can issue InternetGroup Management Protocol (IGMP) join and leave messages and can sendmembership reports to the Media Streaming Subsystem and/or the SystemController. When a system user changes a channel, the UCD can notify thesystem that it does not need the old multicast stream and needs to joina new group. It then receives the new stream, decodes the stream, andeither outputs the signal, or sends the decoded signal to another outputdevice. The UCD can be firmware or software upgradeable to allow forseamless revisions of codecs, the GUI and other applications on the UCDor system. Further, some UCDs may be allowed to store content, forexample recording multiple signals of broadcast television fortime-shifting purposes; typically referred to as a digital recordingdevice (DVR). The system according to the present invention can compriseDVR capabilities through use of a hard drive in the UCD. Since thesystem can be using a low bitrate video codec, the DVR functionality maynot require encoding of the signals, just stream capture to the harddrive. Since the signals are typically encrypted, each DVR feed can beprotected. For ADSL deployments, the number of streams that can becaptured is dependent on the bandwidth available to the UCD. For examplein most cases the available bandwidth can facilitate recording of 3-4video channels per DSL line. In cable systems, for example, the entiremulticast bandwidth may be available to each UCD, thereby making thehard drive or the Ethernet connection limit the recordable feeds tobetween 30 and 500 video channels, for example.

At the UCD, the payload data on all the program slots dedicated to thedata program such as the audio and video data can be decompressed backto its original resolution minus any losses due to compression, andconverted to a signal format suitable for output, such as television,computer monitor or other display device. For example, if the displaydevice is a TV that is an NTSC, PAL or SECAM TV, an appropriate analogsignal format such as an NTSC signal modulated onto RF channel 3 or 4 isgenerated. If the UCD is coupled to the video or S-video and audioinputs of the TV that bypass the tuner, the video and audio data can beconverted into analog composite video and audio signals. If the TVconforms to either a high-definition or digital standard, then the videoand audio data may be sent from DV-I, 1394, or any other appropriatedigital interface. A Set-Top Box (STB) or other UCD may also outputdigital audio signals through standard interfaces such as S/PDIF. Insome embodiments, each STB can have a wireless input unit such as awireless keyboard or a remote control. As an example, one can provideextra features if an intelligent remote or keyboard is used. Each ofthese intelligent remotes can have a bidirectional radio frequency orinfrared link to the STB or other UCD, and each of these remotes canhave a miniature display thereon upon which digital data associated witha program may be displayed either with or without simultaneous displayof the data on the TV. Messages can be displayed on the mini-display onthe remote only or both on the mini-display on the remote and on the TVor other output device also.

In one embodiment, the present invention comprises a Set-Top Box (STB)that is able to decode transmitted compressed data and output a signalto a display device, such as a television and/or audio receiver. The STBcan include a polling/interrupt protocol enabling IP communication inthe STB with a multi-processor coupled implementation of a DigitalSignal Processor (DSP) and a Central Processing Unit (CPU). This coupledimplementation of a DSP and CPU can provide for an increase inproductivity of the DSP, as the operating system and other applicationssuch as an Internet browser can reside on the CPU. The coupledimplementation can overcome numerous limitations of having a DSP aloneby allowing increased functionality through a larger instruction set,and a more flexible environment with a wide variety of softwareapplications. The STB can be connected to a high-speed,quality-of-service (QoS) enabled communication network providing accessto the gateway. The polling/interrupt protocol enables uniquecommunication between a DSP and an Interprocess Communication/RemoteProcedure Call (IPC/RPC) stack.

The STB can decode the audio/video stream that is pulled from thegateway, parse out programming and media information from the stream,and produce a graphics overlay to display this programming and mediainformation, which can be layered over a video stream. Further, allsoftware and codec information that resides on the STB can be fullyupgradeable and not hardwired into the board. The STB can provideseamless integration with other IP-based services, for example websurfing, Voice-Over-IP, IP video phone, instant messaging, eCommerce,and the like. The STB may also connect to a home computer network whichcan provide extended media services such as applications, photos, audio,and video interaction. The home computer could also run the entire STBsoftware for those instances where it is desirable to have a computer asthe UCD.

The STB CPU can communicate with the DSP via a polling/interruptprotocol. In one embodiment, the present invention uses the RPC/IPC asthe base communication layer upon which the following subsectionscommunicate between the host CPU and the multimedia DSP; namely thevideo, audio, graphics, and codec API. The Video API is responsible forgetting a video display buffer and adding to a display queue. Likewise,the Audio API is responsible for getting an audio buffer and adding toan output queue. The Graphics API is responsible for rendering Picturein Picture (PIP), Electronic Programming Guide (EPG) or any other imagedata on top of the video signal. Finally, the Codec API is where thevideo and audio codecs are communicated with to encode/decode multimediadata.

In one embodiment of the present invention, FIG. 6 illustrates theset-top box indicating the various functions of each of the chipcomponents of the STB. The IXP 600 is the general processor (CPU)responsible for the user interaction, graphical interface and the input.The BSP 610 is the special multimedia DSP processor responsible forvideo decoding and output. FIG. 7 illustrates the software functionalityof the IXP, the general purpose processor and the BSP, the multimediaprocessor according to one embodiment of the present invention. FIGS. 6and 7 illustrate that the BSP 610 is responsible for the video decodingand signal display, while the IXP 600 ensures that the audio and videoare synchronized. The IXP is further responsible for the user interface,user interaction and channel selections. In one embodiment, the BSP canhave a RF modulator in order to allow for channel pass-through.

In one embodiment, when a STB is used, upon power up the STB mayinitialize and configure its hardware and software systems. Uponinitialization, the STB may display through a television the initialgraphical user interface (GUI) allowing the system user to selectprograms and services. User identification can be loaded automaticallyand after the user authentication is completed, the STB may display thesystem's main GUI page. The system user can select the category ofprogramming desired such as news, sports or movies. The system user mayinput selections within a particular subcategory, such as thesubcategory of football under the general category of sports. The systemuser may use a television remote control device to navigate a virtualkeyboard displayed on the television set and enter his or herselections. The system user can confirm his or her selection of aparticular program selecting and activating the selected program. Thesystem user can select various functions such as pause, rewind, or fastforward applied to the program being displayed on the television set.The system user can select particular functions by using the inputdevice, such as a television remote control or wireless keyboard, toselect the special functions available by navigating and selecting thedesired function from an On-Screen Display (OSD). The system user mayterminate the display of the particular program by selecting the stopfunction or home icon on a title bar of the GUI. The selection of thestop/home button can allow the system user to return to previous GUIswhere one may enter a new category, sub-categories and programselection. It will be apparent to those skilled in the art that otherGUIs and program selection means may be used to implement the programselection function.

In one embodiment, the GUI can allow the system user to select theprograms and functions one desires by navigating through an intuitivelystraight-forward program display interface. For example, the system usermay select a desired channel from a list of available channels in afirst step. The GUI opens multiple new windows, displaying the availableprogram selections broadcast over that channel during a given timeperiod. It will be apparent to those skilled in the art that the GUI maybe customized by the user service level agreement and that access tocertain programs may be restricted. This may be accomplished by eithernot displaying the programs and channels to which access is restrictedor not allowing the selection of such programs and channels. Selectionof certain programs or channels may also be restricted by the systemuser for purposes such as parental control.

Each customer's premises may allow signals and data from other sourcesbesides a single broadband source such as a DSL line or a cable modem tobe supplied to the peripherals coupled to the gateway by a LAN. Typicalgateways can have satellite transceivers, cable modems, DSL modems, aninterface to the public service telephone network and tuners forconventional TV antennas. All these circuits can be interfaced to one ormore local area networks through an IP packetization and routing processand one or more network interface cards.

System Controller

The System Controller can provide management and control of the systemcomponents and services provided by the system. The System Controllercan be designed so that all independent processes are capable of runningon the same hardware or being moved to different hardware as the systemload increases. Typically, however, there can be many separatecomponents each performing specific functions. The System Controller canbe comprised of an Encoder Element Manager (EEM), a Data-on-DemandElement Manager (DOD-EM), a Set-Top Box Element Manager (STB-EM), aNetwork Element Manager (NEM), Digital Video Broadcasting ServiceInformation (DVB-SI), a Billing System (BS) interface, an ElectronicProgram Guide (EPG) server, a Conditional Access System (CAS), and aMaster Control Application. As would be readily understood, many taskscan be performed by one particular device or manager depending on thedesign of the System Controller.

The Encoder Element Manager (EEM) can provide provisioning and status ofthe encoders. It can also configure the cross-connect layer and theswitch/router to allow a proper source to match the desired service. Itcan also handle redundant or back control of the encoders. If an encoderbecomes non-functional or needs to be taken offline, the EEM may bring anew encoder online to replace the failing encoder. The functions of theEEM may include such tasks as starting and stopping capturing, channelmanagement issues such as smooth swapping or transition from one channelto another in case of hardwire channel failure and other such managementissues. Furthermore, the EEM may perform such functions as turningchannels on and off, or controlling the format, the resolution and thespeed of the encoding process. In one embodiment, the EEM may be aseparate dedicated CPU.

The Data-on-Demand Element Manager (DOD-EM) can provide the provisioningand status of the Data-on-Demand Server. It can monitor content, andfacilitate communication between the DOD server and other elements inthe system.

The Set-Top Box Element Manager (STB-EM) can contain a database of allSTBs in the network, and in one embodiment, the STB-EM database cancomprise the UserID, IP/MAC address, serial number and can contain allservices that each STB is authorized to receive. The STB-EM can alsoprovide initial configuration information to each STB. The STB-EM can beable to communicate with the EPG server, the CAS and also the VODserver, through the Subscriber Management System, thereby enabling it toprovide valid data to the STB. The CAS interface can be controlled bythe STB-EM which can allow IP/MAC addresses to access the content on thesystem. The STB-EM may also include a separate STB server that cancontrol applications, software and maintenance of STBs. The STB servercan interact with the STBs to update the firmware and/or software forthe codecs on the STBs, as well as providing patches and revisions toall software on the STBs, including the Graphical User Interface (GUI)from which system users can access the system. Further, the STB Servermay include a web server and personalized user interface for systemusers, which can be accessed by the STBs. Using such an interface,system users may access a plurality of dynamic and/or personalizedservices provided through the system.

The Network Element Manager (NEM) can provide provisioning and status ofall network devices such as routers, switches, etc. A database can bemaintained on the NEM for the status of all network elements in order tohelp in fault tolerance and fault isolation. The NEM can provide for theallocation of network resources, such as bandwidth, IP addresses,connectivity, etc.

System Information and Announcement Services can also be providedthrough the System Controller. Using the Digital Video BroadcastingService Information (DVB-SI) standard, metadata regarding services canaccompany broadcast signals and assist the UCDs and system users innavigating through the array of services offered. The DVB-SI can begenerated by the System Controller to enable UCDs to understand how tolocate and access services on the network.

A Billing System Interface may also reside on the System Controller tointerface with an external billing system. Transactions can be based onthe Common Billing Interface specification. The billing system interfacecan distribute and collect transaction information from variouscomponents of the System Controller.

The Electronic Program Guide (EPG) server can act as a bridge between aguide information provider and the System Information generationprocess. The EPG server can periodically collect guide information froma service provider. The information can be packaged and mapped onto theactual channel line up defined in the local network. Once theinformation is packaged for a particular network, the data can be passedto the System Information generator for insertion into the network. TheEPG can be linked to a CAS interface and a BS interface to providecustomized EPG data based on the service level of each system user.

A Conditional Access System (CAS) can provide for the encryption ofservices provided by the system. The CAS can provide EntitlementManagement Messages (EMM) and Entitlement Control Messages (ECM) tocontrol access to the services. The EMMs can be targeted to a specificdecoder or user device, whereas the ECMs can be specific to a program orservice. An EMM can provide general information about the subscriber andthe status of the subscription and can be sent with an ECM. The ECM canbe a data unit that can contain the key for decrypting a transmittedprogram. The CAS can be capable of preventing someone from joining abroadcast stream that they have not paid for. Even if someone was ableto join that broadcast stream, the media encryption routines (DRM) canrender the streams unusable for those that have not paid for them

A Master Control Application can be responsible for control of servicesin the network. The Master Control Application can maintain a databaseof the service definitions, which can be based on the informationprovided via the BS interface. The service definitions can be used asthe basis for the generation of the system information and to establishwhich services will require the CAS. The Master Control Application canprovide a user interface for controlling and monitoring the overallsystem. The user interface can show a graphical representation of theelements and connectivity of the network elements, as well as providingmonitoring of alarm indications and event logging.

In one embodiment of the present invention, FIG. 8 illustrates theoverall system components and the interconnectivity between thecomponents integrated into the system controller. FIG. 8 illustrates thecommunication flow and interactions of the various modules associatedwith this embodiment of the present invention, wherein this figureemphasizes the communication flow associated with an IP broadcast videohead-end. In particular there are substantially two symbiotic functionsof a subscriber-based system, namely the delivery of the desiredinformation and the billing system, wherein these two functions arelinked via the Conditional Access System (CAS). The CAS acts as a layerbetween the data, for example the video stream, EPG, and the billingsystem and as a result typically data flows are directed through theCAS.

In one embodiment of the present invention, the Subscriber ManagementSystem (SMS) can be a subcomponent of the Billing System, and can keeptrack of system users and their IDs in the system. When the MasterControl Application instantiates a change to the provisioninginformation for an individual on the system via the SMS/Billing System,communication can be transmitted to the CAS, the EPG and VOD server toupdate the access privileges of that particular system user.

Gateway Means

The system can include a gateway means for receiving compressed digitaldata from the Media Streaming Subsystem and preparing the data fortransmission over a broadband communication network to a system usersending a request. The wide band of frequencies provided by a broadbandcommunication network can allow for multiplexing of data that may beconcurrently transmitted on many different frequencies or channelswithin the band. Broadband communication can allow for the transmissionof more data in a given time, thus providing a high data transmissionrate. The actual width of a broadband communication channel may varyfrom technology to technology. The gateway means allows for seamlessintegration of various telecommunications services for deliveringvideo/voice/data unified services. The gateway means may be designed toaccomplish wire-speed IP routing and provide a single service accesspoint for multiple telecom services and connections to the existingtraditional service-specific networks and access networks.

In one embodiment, the backbone carrying the broadband communication maybe based on a fast Ethernet architecture. Alternatively, the broadbandnetwork service may be based on an Asynchronous Digital Subscriber Line(ADSL) system or Hybrid Fibre-Coax (HFC).

The gateway means can comprise both a core network and an accessnetwork. The core network can be both IP and Ethernet-based, can supporthigh bandwidths, and can be scalable. The core network can be a backboneof Ethernet routers that support the Internet Group Management Protocol(IGMP) on the edge with a high-end fibre transport system. IGMP canprovide a standard for multicasting and can be used to establish hostmemberships in particular multicast groups on a single network. Themechanisms of the protocol can allow a host to inform its local router,using Host Membership Reports, that it wants to receive messagesaddressed to a specific multicast group. The core network can connect toan access network via a layer three/four switch or router. A broadbandswitch, bridge or hub may be used to control and subdivide the trafficover the broadband connection into smaller bandwidth channels. Forexample, a 2 GB broadband channel may be divided into 24 or any othernumber of 10 or 100 MBit/s Ethernet links. The data storage andprocessing capabilities of the content creation and processing unitenables the system to provide time-shifted television services, whereinprogramming for N number of channels may be available on demand to auser regardless of their location within the network. The switch candistribute traffic from the high capacity backbone to a lower capacityaccess network. The switches can have efficient switching and support ahigh quality of service (QoS).

The access network can be one of many common technologies used toprovide broadband access to a client-end. This can include HybridFibre-Coax (HFC), Digital Subscriber Lines (DSL), Integrated ServicesDigital Networks (ISDN) such as Broadband ISDN, wireless, etc. In oneembodiment, a DSL Access Multiplexer (DSLAM) may be used to bridge theIP network to the copper lines running into a subscriber's home. TheDSLAM can support IGMP and QoS to support the video and high-speed dataservices of the system. The DSLAM can link to the edge switch viaGigabit Ethernet, DS3 (T-3 Carrier) Ethernet over a Synchronous OpticalNetwork (SONET), or the like. The DSLAM can deliver the desiredmulticast stream to the appropriate subscriber through IGMP. Multicasttraffic can typically only be sent to ports requesting to be a member ofa particular multicast group. The DSLAM can monitor IGMP messages beingsent from each UCD and can forward these messages to the edge routeronly when necessary. It can forward all queries, join reports andmembership reports and can forward leave messages only as needed. TheDSLAM can track membership of each port and can forward multicasts onlyto those ports requesting membership in a particular group.

The access network can connect to a home network containing multiplePCs, STBs, and other User Computing Devices. In one embodiment, a DSLmodem can act as a bridge forwarding all requests to the DSLAM andforwarding data from the DSLAM back to the UCD. The Ethernet port on themodem can be full duplex, so that data uploads will not interfere withdownstream multicast traffic. The modem can be connected to an Ethernetswitch/router, which will allow each UCD to have its own connection.

In one embodiment, wideband Internet access IP packets can beencapsulated into Ethernet packets by gateway or cable/DSL modem andaddressed to the User Computing Device. The network interface card of aUCD can receive the Ethernet packets, strips off the Ethernet headersand pass the IP packets up through the IP protocol stack to theapplication that requested them. If the application has IP packets tosend back out to the Internet, the packets are generated in theapplication and sent down to the network interface card (NIC). The NICencapsulates them into Ethernet packets and transmits them to thecable/DSL or other modem. The modem then takes these packets andtransmits them to Media Streaming Subsystem via the gateway means. Forexample, if the modem is a cable modem and the upstream data path ishybrid fibre-coax, then the IP packets are disassembled and interleaved,Trellis encoded, code division multiplexed onto whatever logicalchannels are assigned to cable modem and QAM modulated onto the RFcarrier being used to frequency division multiplex the upstream datafrom the downstream data. The Media Streaming Subsystem can receive theupstream signals from the cable modem and recover the IP packets in aconventional manner and routes the IP packets out to the Internet over adata path to a server or router coupled to the Internet.

Telephony can work similarly. The gateway means is typically coupled toa known T3 interface circuitry that is responsible for gathering bytesfrom T3 timeslots assigned to a particular conversation and packetizingthem into IP packets addressed to, for example, a particular UCD. TheseIP packets are culled out of the stream of packets and output in theoutput stream devoted to the channel and program slot to which it hasbeen assigned for a particular session and then transmitted downstream.The IP packets are recovered and encapsulated into Ethernet or other LANpackets at the modem by a modem and then transmitted to the designatedUCD. Signals generated by UCD for transmission back to the MediaStreaming Subsystem would follow the reverse sequence of events usingwhatever form of multiplexing and modulation that is conventional forthe upstream path. If the upstream data path is shared by all thecustomer premises for both upstream and downstream data transmission,then some form of upstream multiplexing such as SCDMA, CDMA, FDMA orTDMA is used to separate the upstream data from the various customers.In addition, the upstream data typically must be multiplexed to keep itseparate from the downstream data. Typically, FDMA is used for thatpurpose but other forms of multiplexing could also be used. If thedownstream and upstream data paths are DSL lines, there may be no needfor multiplexing to separate the data from different customers sincecustomers each get their own DSL line, and conventional DSL multiplexingto separate upstream from downstream data can be used.

A DSL modem in the gateway means can be devoted to each DSL line to asystem user. Each DSL modem at the gateway means can have a conventionalstructure. Each DSL modem at the gateway means and the system user'spremises can function to send and receive information on three channels:a separate analog channel for Plain Old Telephone Service (POTS); a highspeed wideband downstream channel based upon T1 specifications inincrements of 1.536 Mbps up to 6.144 Mbps, for example referred toherein as the wideband channel; and, a bidirectional channel provided inincrements of 64 Kbps up to 640 Kbps for example referred to herein asthe bidirectional channel and which can carry requests and upstreamdata. DSL service is described in Horak & Miller, Communications Systemsand Networks, Voice, Data and Broadband Technologies (1997) M&T Books,Foster City, Calif.

The system can be capable of passing closed caption data as found online 21 of the Vertical Blanking Interval (VBI) of NTSC video signals.The encoders can parse out the VBI and the Extended Announcement System(EAS) information and send it along with timestamp information to thebroadcast stream. This data can be reinserted into the output of theUCD. If the UCD is a STB, for example, the STB can capture the data andsend it to the graphics output chip to be rendered in normal fashion forthe television. The format of the data can conform to CEA-608-B. Thesystem can be capable of utilizing other VBI data other than closedcaption data, such as through the North American Broadcast TeletextSystem (NABTS) and the Neilson rating service data known as AMOL.

The system can be capable of supporting standard copy protection on allanalog and digital outputs at the UCD. This capability can enable thesystem to restrict the subscriber from copying the output. Further, thesystem can be capable of encrypting and/or scrambling all content duringthe encoding process.

This system can be capable of supporting the Emergency Alert System asrequired by the FCC.

The system can be capable of providing backup or redundant components orsub-systems throughout the Compressed Data Creation Subsystem, MediaStreaming Subsystem and gateway means. Switch-over to backup systems canbe under both automatic and manual control. Manual control can be usedto provide maintenance and repair of components and subsystems.

The system can be capable of a pay-per-view service by granting accessto system users that are pre-authorized via the Conditional AccessSystem to decrypt or descramble video/audio programming during aspecified interval. In addition, the system can be capable of an impulsepay-per-view service by granting access to system users requestingauthorization via the UCD to decrypt or descramble video/audioprogramming. The impulse pay-per-view service can also be subject toauthorization via the CAS. Both pay-per-view services can becontinuously transmitted or streamed throughout the network only duringthe specified interval that an event is active. The pay-per-view servicecan be contrasted with, for example, the DOD service where data isrequested by a system user and is sent only to that system user and notbroadcast throughout the network.

The system can be capable of delivering non-encrypted or encryptedaudio-only programming, and restricting access, if encrypted, to onlythose subscribers pre-authorized via the CAS. This service can becontinuously transmitted or streamed throughout the network using a“push” model, such as RTP using IP multicast, for example. The servicemay be accompanied by data that provides information about the currentaudio program, such as title track, data, or still images that areupdated at some interval.

The system can be capable of delivering multiple audio streams forvideo/audio programming services that require second language audio.

Channel Zapping Means

In one embodiment, a requirement for a broadcast media over IP solutionis the ability to cope with a large number of channel changes or zappingas system users surf channels. Since the channel switching is actuallyoccurring in the network there can be latency and performance issuesthat can possibly cause the channel changing experience to be too longfor the subscriber. A typical UCD can change channels and display videoin less than a second. In a very large network where there are a largenumber of subscribers sending channel change requests into the network,the edge switches may become overloaded, thus causing the channel changeto extend beyond the one second mark. Also, each channel change time canbe dependent on the load in the network. If the load is high and theswitches are loaded, then the channel change can be long and if thenetwork is lightly loaded then the channel change time can be short. Inorder to provide a typical system user experience, the networkcomponents, loading, and turnaround time typically are designed to allowfor all channel changes to be less than one second. The UCD can use IGMPjoin/leave messages in order to connect or change channels. The switchcan wrap all the IGMP information into the stream, whereby the DSLAM canconduct the stream join/leave for the UCD. Each channel change requestcan typically only be made aware to the DSLAM, so central officeequipment for example will typically not be flooded with channel changerequests. It may be possible that a non subscribing UCD may connect to asignal not allowed in the provisioning information; however, that signalwill not have decryption keys, which is a task of the CAS, therebyrending the stolen signal useless.

EXAMPLE Video Encoding System

FIG. 9 illustrates the program flow control of the video encoding systemor the encoding/transcoding system according to one embodiment of thepresent invention. The video encoding system comprises a plurality ofDSP based units 910 each of which can be started, initialized andcontrolled by a DSP Managing Thread 901 which can create and control oneor more Real Time Video Encoders 903 which in turn can create andcontrol one or more DSP Encoders 905 which control the encoding for eachDSP based unit. A Real Time Video Encoder can control each DSP basedunit which can encode video in real time. The Distribute Thread 907controls the flow of video frames from the Raw Video Frame Queue 906which need to be encoded by the DSP Encoder 905 and also controls theflow of encoded video frames in the Compressed Video Frame Queue 913.Video Media Flow 912 and Video Source 911 program flow componentscontrol the source of frames for the Real Time Video Encoder 903. Theprogram flow components 902 can control the hardware and software objectinitialization. It is understood, that a DSP based unit can comprise twoor more DSPs.

FIG. 10 illustrates a video encoder method according to an embodiment ofthe present invention. This method can utilize, for example, a TI™ DSP1010 which can capture video frames into SDRAM 1020 of the TI™ DSP, cangenerate a PCI interrupt invoking the IXP 1030, and can transfer theaddress of the frame to the IXP SDRAM 1040 via DMA (direct memoryaccess). The IXP then calls the program flow control described in FIG.9, for example, to invoke one or more BSP processors 1050 and passespointers to the Y, U, and V components to the BSP SDRAM 1060. It isunderstood that a multiprocessor architecture of the video encoder canbe abstracted in the program flow control. The BSP can request the framefrom the TI™ DSP card via a PCI interface and the TI™ DSP can transmitthe frame to the BSP SDRAM via DMA. The BSP encodes the frame andnotifies the IXP via a call-back function that can provide a pointer tothe compressed frame information, which can reside in the BSP SDRAM.Subsequently, the IXP copies the compressed frame data into its SDRAMwhich can be formatted, for example, into RTP packets for subsequenttransmission to the MSS or saved on a storage device.

FIG. 11 illustrates a video encoder method according to anotherembodiment of the present invention. This method is similar to the oneillustrated in FIG. 10. The TI™ DSP 1110, utilizing its SDRAM 1120, andcan additionally assign the video sequence for distributed processing byone or more BSP processors 1150. This allows the TI™ DSP to transferframes to the BSP SDRAM 1160 via DMA. The rest of the processing of thevideo signal is similar and the IXP processor 1130 with its IXP SDRAM1140, when receiving an interrupt from the TI™ DSP, can call the programflow control software to invoke the encoding process.

FIG. 12 illustrates a video encoder method according to anotherembodiment of the present invention. In this method one or more BSPprocessors 1250 can autonomously encode a stream of video data withoutmediation by the IXP processor 1230 or its IXP SDRAM 1240. The IXPprocessor initiates one or more BSP processors 1250 and can forwardframe data into the BSPs SDRAM 1260 for processing by the encodingprocess. Similar to the method illustrated in FIG. 11, the TI™ DSP 1210can assign video data for processing by one or more BSPs and candirectly transfer video frames into the BSPs SDRAM 1220 via DMA. It isunderstood, that the encoder parameters can be controlled by an IXPprocessor 1230 and that such parameters can be requested by each of theone or more BSP processors 1250 via, for example, RPC or IPC.

EXAMPLE The Set Top Box API

In one embodiment of the present invention, the application programminginterface (API) for the set-top box is provided by the following. Thereare essentially five separate APIs integrated into this embodiment ofthe set-top box, namely the Video API, the Audio API, the Graphics API,the RPC/IPC API and the Codec API.

Section 1: Video API (a) InitVideo( unsigned int uiWidthParam, unsignedint uiHeightParam, double dFramerateParam) Description: This routinerequires 3 input parameters to initialize the video display driver,including the video width and height, as well as the video play backrate. It can allocate the video handle for video display. Parameters:unsigned int uiWidthParam; the video width unsigned int uiHeightParam;the video height double dFramerateParam; the frame rate (b) DeInitVideo(VIDEOVAR *pvideovarParam) Description: This routine can de-initializethe video display handler. It can take the video display handle pointeras the input. Parameter: VIDEOVAR *pvideovarParam; the video displayhandle pointer (c) GetVideoBufferPtr( VIDEOVAR *pvideovarParam, unsignedchat **ppucFrameParam, int iBlockParam) Description: This routine canget a video display buffer from the video driver. Parameters: VIDEOVAR*pvideovarParam; the video display driver handle unsigned chat**ppucFrameParam; the returned buffer pointer from the display driverint iBlockParam; the flag if the function should be blocked until abuffer is returned. (d) AddVideoBuffer( VIDEOVAR *pvideovarParam,unsigned char *pucFrameParam, unsigned long long ullTimeStampParam, intiBlockParam) Description: This routine can put the filled video displaybuffer to the video driver for display. Parameters: VIDEOVAR*pvideovarParam; the pointer to the video display handle unsigned char*pucFrameParam; the pointer to the filled video buffer unsigned longlong ullTimeStampParam; the time stamp that the video is displayed intiBlockParam; the flag if the function should be blocked until a bufferis returned.

Section 2: Audio API (a) InitAudio( unsigned int uiPCMBufferSize,unsigned int uiNumChannels, unsigned int uiSamperate, unsigned intuiSampleSize, BufferFreeCallback userCallback, void * firstBuffer)Description: This routine requires 6 input parameters to initialize theaudio playback drive, including the audio buffer size, audio channels,sampling rate per channel and bits per sample. It can allocate the audiohandle for audio playback. Parameters: unsigned int uiPCMBufferSize; theentire buffer size allocated for the audio driver unsigned intuiNumChannels; the channels number of the audio stream unsigned intuiSamperate; the sampling rate of the audio stream unsigned intuiSamperate; the bit depth of each audio sample BufferFreeCallbackuserCallback; the user specified call back function void * firstBuffer;the pointer to the audio buffer (b) DeInitAudio( AUDIOVAR*paudiovarParam) Description: This routine can de-initialize the audioplayback handler. It takes the audio playback handle pointer as theinput. Parameter: AUDIOVAR *paudiovarParam; the audio driver handle (c)GetAudioBuffer( AUDIOVAR *paudiovar, int wait) Description: This routinecan get an audio playback buffer from the audio driver. Parameters:AUDIOVAR *paudiovar; the audio driver handle int wait; the flag if thefunction should wait until a buffer is returned. (d) PutAudioBuffer(AUDIOVAR *paudiovar, unsigned char *pucAudio) Description: This routinecan put a filled audio buffer to the audio driver for playback.Parameter: AUDIOVAR *paudiovar; the audio driver handle unsigned char*pucAudio; the pointer to audio buffer

Section 3: Graphics API (a) gfxInit( tGfxStatus *pStatus) Description:This routine can use internally defined constant parameters toinitialize the graphic driver. It can allocate the graphic handle forgraphic display. Parameter: tGfxStatus *pStatus; the pointer to thereturn status (b) gfcDeInit( GRAPICSVAR *pgraphicsvarparam) Description:This routine can de-initialize the graphics display handler. It can takethe graphics handle pointer as the input. Parameter: GRAPICSVAR*pgraphicsvarparam; the graphics driver handle (c) gfxRefreshBuffer(GRAPHICVAR *pgraphicsvarParam, const tGfxSquare *pGfxSquare)Description: This routine can refresh the graphic display at thebeginning to avoid graphic hangs. Parameter: GRAPHICVAR*pgraphicsvarParam; the graphic driver handle const tGfxSquare*pGfxSquare; the pointer to the graphics square structure (d)setFrameBufferUpdate( ) Description: This routine can update the newgraphic once it is available.

Section 4: RPC/IPC API (a) InitPSIVIntHandler( tBspMemoryMap *pmmap,GRAPHICSVAR *pgraphics, VIDEOVAE *pvideo, AUDIOVAR *paudio) Description:This routine needs the video, audio and graphics handlers as the inputparameters. It can initialize the RPC/IPC communication. It can allocatethe RPC/IPC handle for the RPC/IPC communication. Parameter:tBspMemoryMap *pmmap; the global memory for the BSP memory map structureGRAPHICSVAR *pgraphics; the graphic driver handle VIDEOVAE *pvideo; thevideo driver handle AUDIOVAR *paudio; the audio driver handle (b)ServeRPC( ) Description: This routine can responds to any IPC message.

Section 5: Codec API (a) InitializePSIV( volatile _uncached_int *pioSema0, volatile _uncached_int * pioMsgSize0, volatile_uncached_unsigned char * pcBuffer0, volatile _uncached_int * pioSema1,volatile _uncached_int * pioMsgSize1, volatile _uncached_unsigned char *pcBuffer1, int Length, int * width, int * height) Description: Thisroutine can decode the first video frame and can initialize the IRISdecoder engine. Parameter: volatile _uncached_int * pioSema0; thepointer of the semaphore of the video buffer0 volatile _uncached_int *pioMsgSize0; the pointer of the actual bytes size of the video buffer0volatile _uncached_unsigned char * pcBuffer0; the pointer to the videobuffer0 volatile _uncached_int * pioSema1; the pointer of the semaphoreof the video buffer 1 volatile _uncached_int * pioMsgSize1; pointer ofactual byte size of the video buffer 1 volatile _uncached_unsignedchar * pcBuffer1; the pointer to the video buffer1 int Length; themaximum size of the video buffer int * width; the pointer to the widthto be returned int * height; the pointer to the height to be returned(b) DecodeLoopPSIV( tPSIVIntData* pPSIVIntData, void (*pFunc)(chat *pcParam), char *pcFuncParam, double dFrameRateParam) Description: Thisroutine can decode all the frames in a loop. Parameter: tPSIVIntData*pPSIVIntData; the pointer to the IPC handle void (*pFunc)(chat *pcParam); the callback function pointer char *pcFuncParam; the parameterpassed into the callback function double dFrameRateParam; the frame rate

The embodiments of the invention being thus described, it will beobvious that the same may be varied in many ways. Such variations arenot to be regarded as a departure from the spirit and scope of theinvention, and all such modifications as would be obvious to one skilledin the art are intended to be included within the scope of the followingclaims.

1. A system for providing a plurality of system users IP-centric,multi-channel, time-shifted and real-time telecommunications servicesincluding live television, television-on-demand, video-on-demand,streaming audio, audio-on-demand, said system comprising: a) acompressed data creation subsystem for receiving multiple data signalstreams each having one of several industry standard communicationformats, and for converting the incoming data signal streams intocompressed digital data, said compressed digital data being createdusing a predetermined compression scheme; b) a storage means for storingselected compressed digital data and permitting stored compresseddigital data to be retrieved therefrom; c) a media streaming subsystemfor receiving and forwarding streams of compressed digital data, saidmedia streaming subsystem being responsive to a user request andoperative to forward a selected stream of compressed digital data fromeither the compressed data creation subsystem or the storage means to agateway means; d) a gateway means for receiving said compressed digitaldata from the media streaming subsystem and preparing said compresseddigital data for transmission over a broadband communication network toa user sending the user request; and e) a user computing device,connected to the broadband communication network, for receiving theselected stream of compressed digital data and the user computing devicedecompressing and presenting said selected stream of compressed digitalto the system user.
 2. The system according to claim 1, wherein thecompressed data creation subsystem comprises two or more encodingdevices for converting the incoming data signal streams into compresseddigital data.
 3. The system according to claim 2, wherein each encodingdevice comprises one or more digital signal processors.
 4. The systemaccording to claim 3, wherein the one or more digital signal processorsare operatively coupled to a central processing unit in the encodingdevice and the central processing unit manages the flow of predeterminedportions of the incoming data signal streams to the one or more digitalsignal processors operatively coupled thereto.
 5. The system accordingto claim 2, wherein the each of the two or more encoding devices isdynamically assigned portions of the incoming data signal streams. 6.The system according to claim 2, wherein each of the two or moreencoding devices includes a means for adjusting complexity and bitrateassociated with the compressed digital data resulting from the step ofconverting the incoming data signal streams.
 7. The system according toclaim 2, wherein the compressed data creation subsystem furthercomprises one or more backup encoding devices.
 8. The system accordingto claim 2, wherein the compressed data creation subsystem and the usercomputing device each include one or more firmware upgradable devices,thereby providing a means for dynamically changing an encoding schemeassociated with the system.
 9. The system according to claim 1, whereinthe compressed data creation subsystem further generates an I-framechannel representative for each of said incoming data signal streams,thereby providing a means for changing the selected stream of selecteddigital data for subsequent forwarding to the user computing device. 10.The system according to claim 1, wherein the user computing device is aset-top box, said set-top box comprising a multi-processorconfiguration.
 11. The system according to claim 9, wherein themulti-processor configuration comprises a digital signal processor and acentral processing unit, wherein IP communication between themulti-processor configuration can be enabled using a polling/interruptprotocol.
 12. The system according to claim 11, wherein thepolling/interrupt protocol is configured using RPC/IPC as thecommunication layer providing a means for each of a video API, audioAPI, graphics API and a codec API to communicate between the digitalsignal processor and the central processing unit.
 13. The systemaccording to claim 9, wherein the central processing unit provides ameans for system user interaction with the set-top box, generation of agraphical interface for presentation to a user and for receiving theselected stream of digital data, and wherein the digital signalprocessor provides a means for decoding said selected stream of digitaldata.
 14. A method for providing a plurality of system user IP-centric,multi-channel, time-shifted and real-time telecommunications servicesincluding live television, television-on-demand, video-on-demand,streaming audio, audio-on-demand, said method comprising: a) receivingmultiple incoming data signal streams each having one of severalindustry standard communication formats and converting the incoming datasignal streams into compressed digital data using a predeterminedcompression scheme; b) storing selected compressed digital data; c)selecting user requested compressed digital data from the compresseddigital data and the selected compressed digital data in response to auser request and forwarding the user requested compressed digital datato a gateway means; d) receiving the user requested compressed digitaldata in the gateway means and preparing the user requested compresseddigital data for transmission over a broadband communication network toa user computing device sending the user request; and e) receiving theuser requested compressed digital data by the user computing device anddecompressing and displaying the user requested compressed digital databy means of the user computing device.
 15. The method according to claim12, wherein the step of converting the incoming data signal streamscomprises the step of dynamically allocating an encoding device selectedfrom two or more encoding devices to convert a particular portion of theincoming data signal streams.
 16. The method according to claim 15,wherein each encoding device comprises one or more digital signalprocessors operatively coupled to a central processing unit, the centralprocessing unit managing the flow of predetermined portions of theincoming data signal streams to the one or more digital signalprocessors operatively coupled thereto.
 17. The method according toclaim 15, wherein each of the two or more encoding devices independentlyadjust bitrate and complexity of converting the particular portion ofthe incoming data signal streams associated therewith.
 18. The methodaccording to claim 17, wherein the adjustment of the bitrate andcomplexity of converting the particular portion of the incoming datasignal streams is based on a predetermined set of parameters.
 19. Themethod according to claim 14, further comprising the step of generatinga representative I-frame channel for each of said incoming data signalstreams.